{
    title:  'Security Considerations',
    crumbs: [
        { "User's Guide": 'index.html' },
    ],
}
            <h1>Security Considerations</h1>
            <p>Securing applications that are accessible to the Internet is not a trivial task. This page outlines some
            of the issues, and offers best-practices and tips to help you secure your application using Embedthis ESP.</p>
            
            <h2>Contents</h2>
            <ul>
                <li><a href="#updates">Updating ESP</a></li>
                <li><a href="#sandBoxing">Sandboxing</a></li>
                <li><a href="#account">ESP User Account</a></li>
                <li><a href="#chroot">Chroot Jail</a></li>
                <li><a href="#ssl">Securing SSL</a></li>
                <li><a href="#authentication">Authentication</a></li>
                <li><a href="#logFiles">Log Files</a></li>
                <li><a href="#threats">Common Security Threats</a></li>
                <li><a href="#high">High Profile Threats</a></li>
            </ul>
            
            <a id="updates"></a>
            <h2>Updates</h2>
            <p>Even the best application or web framework can experience some security vulnerabilities that are
            discovered after being deployed in the field. It is highly recommended that you stay up to date with the
            latest version of ESP.</p>
            <p><a href="http://www.embedthis.com/">Embedthis</a> provides security protection 
            as part of the ESP commercial license that will proactively notify you of any security flaws
            and will expedite fixes or workarounds to minimize any vulnerabilities.</p>
            
            <a id="sandBoxing"></a>
            <h2>Sandboxing</h2>
            <p>Sandboxing is the term applied to running ESP in a confined environment. When embedding,
            the profile of client access is often well known, and the profile of malicious attacks are often well 
            outside the bounds of this expected profile. The profile includes the rate of accesses, the length of 
            URLs and the size of data submitted by the user.</p>
            <p>ESP has a set of configuration properties that allow you to define a sandbox which specifies how
            ESP must be used for a request to be serviced. By using a well defined sandbox, you can help
            ensure that your application will not be compromised by malicious requests. You should customize the
            sandbox limits to use minimum values and thus provide the most protection.</p>

            <h3>Security Limit Directives</h3>
            <p>The ESP security limits can be used to effectively block some denial of service attacks. 
            Limits should be set as low as possible while still permitting all valid requests and workloads.</p>
            <p>Setting the <a href="config.html#limits">http.limits.requests</a> to a low value can restrict the ability of a malicious client to monopolize
            the server. One attack method for denial of service attacks is to initiate requests, but not conclude the
            request headers. The server is then forced to wait for the client to complete the request before it can
            act. However, setting the <em>http.timeouts.parse</em> property to a low value will abort such requests 
            and prevent such attacks.</p>

            <p>ESP can monitor sandbox limits and trigger defensive responses if access is outside defined norms. See the
            <a href="#dos">Denial of Service</a> section for more details.</p>
            <h3>Sandbox Limit Properties</h3>
            <table title="sandbox" class="ui table segment">
                <thead>
                    <tr>
                        <th>Property</th>
                        <th>Description</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td class="pivot">http.limits.connections</td>
                        <td>Maximum number of network connections. Note a client can open many network connections. A browser
                            session will typically open 4-6 connections.</td>
                    </tr>

                    <tr>
                        <td class="pivot">http.limits.clients</td>
                        <td>Maximum number of simultaneous clients</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.cache</td>
                        <td>Maximum size of the response cache</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.cacheItem</td>
                        <td>Maximum size of a single item in the response cache</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.keepAlive</td>
                        <td>Maximum number of requests to serve using a single TCP/IP connection</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.memory</td>
                        <td>Maximum memory the server can allocate</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.processes</td>
                        <td>Maximum number of simultaneous CGI processes the server will start</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.requestBody</td>
                        <td>Maximum size of the incoming request body. Does not include file upload size.</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.requestForm</td>
                        <td>Maximum size of request form data (POST data)</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.requestHeader</td>
                        <td>Maximum size of the request header</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.requests</td>
                        <td>Maximum number of simultaneous requests from a single client IP</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.uri</td>
                        <td>Maximum size of a URI</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.upload</td>
                        <td>Maximum size of a file upload request</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.limits.workers</td>
                        <td>Maximum number of worker threads to service requests. A single worker may service many requests
                            as ESP will typically not block when serving a request. Workers are assigned to service network 
                            events and are then returned to a worker pool to service the next event.</td>
                    </tr>
                </tbody>
            </table>
            <h3>Sandbox Timeout Properties</h3>
            <table title="sandbox" class="ui table segment">
                <thead>
                    <tr>
                        <th>Property</th>
                        <th>Description</th>
                    </tr>
                </thead>
                <tbody>
                    <tr>
                        <td class="pivot">http.timeouts.inactivity</td>
                        <td>Maximum request and connection inactivity duration. This can be defined per route, so if you
                            have a long running request, create a dedicated route for that request.</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.timeouts.parse</td>
                        <td>Maximum duration to parse the request headers. This should be set very short. 
                            Typically a browser will send all the request headers in one network packet. Recommended
                            value is 5 secs.</td>
                    </tr>
                    <tr>
                        <td class="pivot">http.timeouts.request</td>
                        <td>Maximum request duration. Set this to the maximum time a request can take. This can
                            be defined per route, so if you have a long running request, create a dedicated
                            route and RequestTimeout for it.</td>
                    </tr>
                </tbody>
            </table>
            <p>See the <a href="config.html">Configuring ESP</a> for further details.</p>
            <h2>Defensive Countermeasures</h2>
            <p>ESP includes a monitoring and defensive response framework to mitigate against denial-of-service (DOS) 
            attacks and vulnerability probing. This framework monitors the security sandbox and triggers defenses 
            should any sandbox metric be outside anticipated norms. Monitored metrics can also include the 
            number of requests that result in an error, the number of SSL errors and the total number of requests.</p>
            <p>For example, to ban any client that requests more than 50 unknown URIs per minute:</p>
<pre class="code">
defenses: {
    block: {
        "remedy": "ban",
        "status": 406,
        "message": "Client banned",
        "period": "1hour",
    },
},
monitors: {
    missing: {
        "expression": "NotFoundErrors &gt; 50",
        "period": "1min",
        "defenses": [ "block" ],
    },
},
</pre>
            <p>See the <a href="monitor.html">Monitoring and Defending</a> for further details.</p>
            <a id="account"></a>
            <h2>ESP User Account</h2>
            <p>It is important that you run ESP with the lowest system privilege that will get the job done. If any
            application is compromised, including ESP, then the system will be safest if the compromised application
            has as few privileges as possible.</p>
            <h3>Unix Account</h3>
            <p>On Unix, ESP initially runs as root or administrator and then changes to the user account defined in
            the ESP configuration file via the <em>http.server.account.user</em> property. 

            <a id="chroot"></a>
            <h2>Chroot Jail</h2>
            <p>One of the best forms of isolation for the server is to run inside a 
            <a href="http://en.wikipedia.org/wiki/Chroot">chroot</a> jail. A chroot jail is when an application changes
            its root directory to be isolated from the real file system root directory. Any access then to files 
            outside the jail is protected and impossible. ESP supports chroot jails via the 
            <em>http.server.chroot</em> property.</p>

            <a id="ssl"></a>
            <h2>Securing SSL</h2>
            <h3>Cipher Selection</h3>
            <p>It is important to select a sufficiently long key length and strong cipher to protect SSL communications. 
            It is recommended to use the AES cipher and avoid the older RC4 cipher suite. See the section below regarding 
            <a href="#high">High Profile Threats</a> for threats against the RC4 ciphers. </p>

            <h3>SSL Forms</h3>
            <p>A common practice is to use HTTP for regular communications and to post login forms using SSL. 
            However, this approach is flawed. The web form itself must be served using SSL as well as the URL 
            receiving the login information. This prevents attackers injecting code into the login form and hijacking 
            login credentials.</p>

            <a id="authentication"></a>
            <h2>Authentication</h2>
            <p>It is important to adequately secure all passwords stored at the server. 
            Simply hashing the passwords with MD5 is now insufficient as MD5 and other "fast" hashing techniques 
            can be quickly compromised by dedicated password cracking and hashing tools.</p>

            <p>ESP includes the blowfish cipher as an alternative that is more secure than MD5. 
            The <a href="http://en.wikipedia.org/wiki/Blowfish_(cipher)">Blowfish</a> cipher is especially well 
            suited for password hashing partly. Partly because it is slow, it does not easily succumb to 
            brute-force cracking. </p>

            <p>If you wish to use the Digest authentication scheme, unfortunately you cannot use blowfish as the 
            browser uses MD5 to encrypt the password before transmitting over the wire. This and other 
            shortcomings of Digest authentication should encourage you to select other schemes. A better 
            alternative is Basic authentication over SSL using blowfish to encrypt the passwords. Alternatively, 
            use web form authentication with blowfish for password storage.</p> 

            <p>If using a web page for users to submit their credentials, it is strongly recommended that you use 
            SSL for both the web form page and for the request validating the user credentials.</p>

            <a id="logFiles"></a>
            <h2>Log Files</h2>
            <p>ESP will log errors to the error log and request trace to the trace log. 
            These It is recommended that you regularly review these logs for suspicious activity.</p>

            <a id="threats"></a>
            <h2>Common Security Threats</h2>
            <p>This section details some common security threats and issues and the steps you can take to mitigate them.</p>
            
            <h3>Server Information Disclosure</h3>
            <p>HTTP responses often disclose information that an attacker can use to refine their attack. At a minimum, too much information enables the attack to proceed faster. ESP includes a stealth directive that suppresses unnecessary information. Here is a typical HTTP response from ESP</p>
            <pre class="code">
HTTP/1.1 200 OK
Content-Type: text/html
<b>Server: Embedthis-http</b>
Date: Thu, 15 Aug 2014 22:10:25 GMT
ETag: "cf4ce71-54-51c64a0b"
Content-Length: 84
Last-Modified: Sun, 23 Jun 2014 01:06:19 GMT
Connection: close
Accept-Ranges: bytes</pre>
            <p>Note that by default, ESP does not disclose the web server version number in HTTP headers. 
            You can further restrict information disclosure by defining the <em>http.stealth</em> property.</p>
            
            <pre class="code">stealth: true</pre>
            <pre class="code">
HTTP/1.1 200 OK
Content-Type: text/html
Date: Thu, 15 Aug 2014 22:11:46 GMT
ETag: "cf4ce71-54-51c64a0b"
Content-Length: 84
Last-Modified: Sun, 23 Jun 2014 01:06:19 GMT
Connection: close
Accept-Ranges: bytes
</pre>
            <p>Notice that the <i>stealth</i> property has suppressed the Server header altogether. 
            Attackers will need to work a little harder to know what kind of web server is responding 
            to their requests &mdash; they may move onto another target.</p>
            <h3>Session Hijacking</h3>
            <p>Cookies are used to identify authenticated user sessions. As such, they are a prized piece of information 
            by attackers. The HTTP Set-Cookie response header has an option to prevent client side scripts from ascertaining
            the session cookie value. This can greatly reduce the risk of session hijacking via cross-site scripting.</p>
<pre class="code">
auth: {
    session: {
        visible: false
    }
}</pre>
            <p>The <em>visible</em> session property appends the "httpOnly" value to the Set-Cookie response so 
            the cookie will only be accessible to HTTP requests.</p>
            <pre class="code">Set-Cookie: key=value; httpOnly</pre>
            <a name="mixed"></a>
            <h3>Mixed Transports</h3>
            <p>Is is a bad idea to mix secure and non-secure content in one page. This means a web page should be totally served by HTTP or by HTTPS but not mix transports on one page. The reason is that a page served by HTTP can be compromised and the guarantee of HTTPS and that green-browser https logo is diminished if the form page from
            which the user enters there data is not 100% trust-worthy.</p>
            <a name="dos"></a>
            <h3>Denial of Service</h3>
            <p>Denial of service attacks can be difficult to detect and defend against. However, Embedded 
            devices typically have a well defined, understood and anticipated work load. Unlike enterprise system, 
            which have highly variable work loads, embedded systems typically serve a specific purpose with 
            known clients that follow a more predictable access pattern. This allows an embedded system to 
            define a range of operation that is considered "normal" and to trigger alerts and defenses if 
            access is outside of this "normal" operation.</p>
            <p>ESP provides a <a href="monitor.html">Monitor and Defending</a> framework that can detect many 
            denial of service attacks. The defensive policies can alert and mitigate the attack and help maintain 
            service. It is recommended that all systems consider this framework.</p>
            <h3>Cross Site Scripting</h3>
            <p>Cross-site vulnerabilities have ballooned over recent years. Unfortunately, there is no, single complete cure.
            However, ESP supports the 
            <a href="http://en.wikipedia.org/wiki/Content_Security_Policy">Content Security Policy (CSP)</a> 
            scheme that can go a long way to reduce the exposure. It does this by
            exactly specifying and restricting what cross-site access is permitted.</p>
            <p>The following ESP directive enables the Content Security Policy and restricts all access to the origin
            site. This is a good starting point.</p>
            <pre class="code">
headers: {
    add: {
        "Content-Security-Policy: "default-src 'self'
    }
}</pre>
            <p>See <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/">An 
                introduction to Content Security Policy</a> for more information.</p>
            <p>For Microsoft IE, there is another step specific for IE that is useful. The following ESP directive
            invokes some additional IE cross site protections.</p>
<pre class="code">
headers: {
    add: {
        "X-XSS-Protection": "1; mode=block"
    }
}</pre>
            <h3>Cross-Site Request Forgery</h3>
            <p>Cross site requires forgery or XSRF is an exploit where unauthorized commands are sent from 
            a user that the website trusts. Unlike cross-site scripting, which exploits the trust a user has for a
            site, XSRF exploits the trust that a site has in a user.
            See <a href="https://en.wikipedia.org/wiki/Cross-site_request_forgery">Wikipedia</a> for more details.</p>

            <p>ESP can generate mitigate the XSRF threat by generating an XSRF token that is required in all POST forms.
            This token is dynamically generated on the server and saved in the ESP session. It is sent to the browser
            in the <em>X-XSRF-TOKEN</em> HTTP response headers and may also be optionally generated in form web pages 
            as a hidden input field.  When the form is posted, ESP checks that the token matches the token saved 
            in the ESP session storage.</p>

            <p>To enable XSRF token checking, set <em>http.xsrf</em> to true. To generate an XSRF token in an ESP
            form page, use the <em>inputSecurityToken</em> API. This generates a hidden input field containing the XSRF
            token.</p>

            <pre class="code">&lt;% inputSecurityToken(); %&gt;</pre>

            <p>This generates:</p>
            <pre class="code">&lt;input name='-xsrf-' type='hidden' value='TOKEN-VALUE'&gt;</pre>
            <p>If using Ajax to issue POST requests, you will need to add the security token to the posted data fields
            manually. You can call securityToken to add the token to the page HTTTP headers. For example:

<pre class="code">
&lt;script&gt;
    securityToken();
&lt;/script&gt;
</pre>
            Then you can extract the security token from the HTTP headers and add to any POST request form fields.
            If you need to access the token value directly in Javascript client-side code, use:
            <pre class="code">
&lt;script&gt;
    var token = "&lt;%= getSecurityToken(); %&gt;"
&lt;/script&gt;
</pre>
            <h3>Hidden Frames</h3>
            <p>Hidden frames may be inserted by attackers to provide a launch-pad for running malicious scripts. Denying 
            the ability to run frames can close of this attack vector.</p>
            <p>The following ESP directive will prevent frames or iframes from running in the web page.</p>
            <pre class="code">Header set X-Frame-Options deny</pre>
<pre class="code">
headers: {
    add: {
        "X-Frame-Options": "deny"
    }
}
</pre>
            <a name="high"></a>
            <h2>High Profile Threats</h2>
            <p>There have been several high profile exploits that pose specific risks and have captured media attention.
            These are addressed specifically below with details on how to mitigate their effects.</p>
            <h3>Crime Exploit</h3>
            <p>The <a href="http://en.wikipedia.org/wiki/CRIME_(security_exploit)">Crime Security Exploit</a> attacks and
            exploits leakage of information due to the varying effectiveness of TLS compression.
            <ul>
               <li>Access to intercept and redirect client communications</li>
               <li>Ability to initiate requests from the client</li>
               <li>Encrypted communications SSL/TLS</li>
               <li>TLS level compression</li>
            </ul>
            <p>By default, ESP does not use TLS with TLS compression and is thus not vulnerable to this exploit. 
            The OpenSSL SSL_COMP_add_compression_method will enable TLS compression, so it is important not to use this
            OpenSSL API.</p>
            <h3>Breach Exploit</h3>
            <p>The <a href="http://breachattack.com">Breach</a> exploit is a variant of the Crime exploit. It attacks and
            discovers private server information, such as CSRF tokens, by observing the compression of HTTP responses over
            SSL. This exploit requires the following to be effective:</p>
            <ul>
                <li>Access to intercept and redirect client communications</li>
                <li>Ability to initiate requests from the client</li>
                <li>Encrypted communications SSL/TLS</li>
                <li>Server-side encryption of dynamic responses</li>
                <li>Unmodified inclusion in the response body of client specified query or form data</li>
            </ul>
            <p>ESP does not dynamically compress response content and so is not vulnerable to this exploit.</p>
            <h3>Beast Exploit</h3>
            <p>The <a href="http://en.wikipedia.org/wiki/BEAST_(computer_security)#BEAST_attack">Beast Security Exploit</a>
            attacks block ciphers used by TLS to access encrypted packets.
            This exploit requires the following to be effective:</p>
            <ul>
                <li>Use of TLS 1.0. This exploit has been addressed in TLS 1.1 and later.</li>
                <li>Ability to position attacker as man-in-the-middle between server and client</li>
                <li>Encrypted communications SSL/TLS</li>
                <li>Using a block cipher.</li>
            </ul>
            <p>Notes:</p>
                <ul>
                    <li>OpenSSL 0.9.6d and later are not vulnerable.</li>
                    <li>ESP 3.3 and later have shipped with fixed OpenSSL libraries.</li>
                    <li>Using RC4 will mitigate the attack if upgrading OpenSSL is not feasible, however this cipher
                    is vulnerable to the Luck 13 exploit described below.</li>
                </ul>
            <h3>Lucky 13 Exploit</h3>
            <p>The <a href="http://www.isg.rhul.ac.uk/tls/TLStiming.pdf">Lucky 13</a> exploit attacks TLS by using varying
            padding for block ciphers. </p>
            <p>This exploit requires the following to be effective:</p>
            <ul>
                <li>Ability to position attacker as man-in-the-middle between server and client</li>
                <li>Encrypted communications SSL/TLS</li>
                <li>Using a block cipher.</li>
                <li>Use of the RC4 cipher.</li>
            </ul>
            <p>Notes:</p>
            <ul>
                <li>Mitigate by not using an RC4 cipher</li>
                <li>RC4 was not the default cipher in any ESP release</li>
            </ul>
            <a name="cve"></a>
            <h2>Documented Vulnerabilities</h2>
            <p>ESP documents discovered security errors in its GitHub issue database 
            at </p>
            <pre class="code"><a href="https://github.com/embedthis/esp/issues?state=open"
            >https://github.com/embedthis/esp/issues?state=open</a></pre>
            <p>Specific issue reports are created for all confirmed or erroneous 
            security reports that receive a CVE classification. You can search for specific 
            CVE numbers or see all via:</p>
            <pre class="code"><a
href="https://github.com/embedthis/esp/search?q=CVE-&amp;type=Issues">https://github.com/embedthis/esp/search?q=CVE-&amp;type=Issues</a></pre>
            <p>Unfortunately some security researchers publish poorly diagnosed security alerts and sometimes do not contact the vendor for confirmation of the report. Consequently there exist some security CVE reports which are bogus. ESP creates parallel CVE issues in the ESP GitHub issue database to comment on these reports and provide accurate resolution information.</p>
            <h2>Other Security References</h2>
            <p>Some of these articles may provide good background regarding security web servers.</p>
            <ul>
                <li><a href="http://www.isg.rhul.ac.uk/tls/TLStiming.pdf"
                    >http://www.isg.rhul.ac.uk/tls/TLStiming.pdf</a></li>
                <li><a href="http://blog.cryptographyengineering.com/search?q=bram+cohen"
                    >http://blog.cryptographyengineering.com/search?q=bram+cohen</a></li>
                <li><a href="http://html5sec.org/">http://html5sec.org/</a></li>
                <li><a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet"
                    >https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet</a></li>
                <li><a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)"
                    >https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)</a></li>
                <li><a href="https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf"
                    >https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf</a></li>
                <li><a href="http://media.blackhat.com/bh-ad-11/Sutton/bh-ad-11-Sutton_Embeded_Web_Servers_WP.pdf"
                    >http://media.blackhat.com/bh-ad-11/Sutton/bh-ad-11-Sutton_Embeded_Web_Servers_WP.pdf</a></li>
                <li><a href="http://www.imperialviolet.org/2012/07/19/hope9talk.html"
                    >http://www.imperialviolet.org/2012/07/19/hope9talk.html</a></li>
                <li><a href="https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf"
                    >https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf</a></li>
            </ul>
            <h2>C Code</h2>
            <p>ESP applications are not immune to security flaws. It is highly recommended that
            you use the <a href="../ref/api/mpr.html">MPR</a> services for all your ESP code. This portable runtime
            has been extensively tested and includes routines to guard against common buffer overflows and other such
            exploits.</p>
            <a name="securedefaults"></a>
            <h2>ESP Secure By Default</h2>
            <p>ESP is designed to be secure by default. This means that the default configuration enables 
            security best-practices to limit cross-site-scripting vulnerabilities. It also implies a fairly
            restrictive security sandbox. This default configuration may be a little too restrictive for your application. 
            In that case, you can easily remove or override these defaults by the relevant ESP directives.</p>
            <p>ESP uses the following built-in configuration for the default route.</p>
            <pre class="code">
SessionCookie           invisible
app: {
  http: {
    auth: {
        session: {
            visible: false
        },
    },
    stealth: true,
    limits: {
      buffer:           "32KB",     /* Default buffer size */
      cache:            "10MB",     /* Max response cache size */
      cacheItem:        "200KB",    /* Per-item max cache size */
      chunk:            "64KB",     /* Default chunk encoding size */
      clients:          100,        /* Max simultaneous clients */
      connections:      50,         /* Max simultaneous connections */
      files:            "unlimited",/* Max open files */
      keepAlive:        200,        /* Max requests per socket connection */
      processes:        "unlimited",/* Max processes to run */
      requestBody:      100K,       /* Max request body data */
      requestForm:      32K,        /* Max request form body data */
      requestHeader:    32K,        /* Max request HTTP headers size */
      responseBody:     "2GB",      /* Max response body size */
      memory:           "200MB",    /* Max memory heap usage */
      requests:         20,         /* Max simultaneous requests */
      sessions:         100,        /* Max client sessions */
      upload:           "2GB",      /* Max file upload size */
      uri:              "8K",       /* Max URL size */
      webSockets:        20,        /* Max Web Sockets */
      webSocketsMessage: "50K",     /* Max WebSockets message size */
      webSocketsPacket:  "50K",     /* Max WebSockets packet size */
      webSocketsFrame:   "4K",      /* Max Websockets frame size */
      workers:           4,         /* Max worker threads */
    },
    timeouts: {
      exit:             "30secs",   /* Max time for app to exit */
      parse:            "20secs",   /* Max time to receive request headers */
      inactivity:       "300secs",  /* Max I/O inactivity for connections */ 
      request:          "infinite", /* Max request duration */
      session:          "30mins",   /* Max user session duration */
    },
    headers: {
        add: {
            "X-XSS-Protection":          "1; mode=block",
            "X-Frame-Options":           "deny",
            "X-Content-Type-Options":    "nosniff",
        },
    },
  }
}
</pre>
